…s on PATH (#22902)

Resolves
[F-613](https://linear.app/aztec-labs/issue/F-613/aztec-installer-shadows-user-forge-nargo-on-path).

The installer used to drop `forge`, `nargo`, `anvil`, `bb`, `pxe`,
`txe`, etc. directly into `~/.aztec/current/bin` under bare names,
silently shadowing user-installed tools in unrelated projects.

Native binaries now live in `~/.aztec/current/internal-bin` (off `PATH`)
and are exposed only via `aztec-<tool>` symlinks in
`~/.aztec/current/bin`. The `aztec` entrypoint is a small wrapper that
prepends `internal-bin` to its subprocess `PATH`, so `aztec test` and
`aztec start --local-network` continue to resolve bundled `nargo` /
`anvil` by basename without leaking them to the user's shell.

`aztec-up/test/no_shadow_user_bins.sh` is a new regression test that
plants user shims for every bare name, asserts the shims win on `PATH`,
and asserts every entry in `current/bin` is `aztec` or `aztec-*`.

Migration notes and the affected tutorials are updated to the new
`aztec-*` names.

The issue mentions appropriately handling binaries calling other
binaries by name. I felt that was overly defensive and we should rely on
tools cross-calling bins with an absolute path. Rather than defending
against this with extra scaffolding in our wrappers, the correct fix is
for the tools to use an absolute bundled path for internal tool calls.

(cherry picked from commit 0aaf27c)

aave_bridge.md was deleted on backport-to-v4-next-staging but
modified by the cherry-pick. Drop the file to match the target
branch state.

We correctly .gitignore prebuilt sqlite artifacts since we fetch and
verify them on build, however, this is inconvenient for users of our
packages, since it leaves the burden of re-vendoring up to them.

This PR introduces an .npmignore file to the sqlite npm package, which
by convention overshadows the .gitignore file when npm produces the
package tarball.

It also includes a verification script to make sure there's no loose
ends in the process

Records the raw cherry-pick state (including conflict markers) so reviewers can see exactly what conflicted before resolution.

Original PR: #22985

Resolve conflicts in #22985 cherry-pick onto v4-next-staging:
- migration_notes.md: keep only the new DeployMethod note. Drop unrelated entries
  (getBlock/getCheckpoint, feeAssetPriceModifier, Domain separators, aztec-up
  table, slasher renames, Unreleased v5 returnReceipt removal) from PRs not yet
  backported.
- txe_oracles.nr / constants*.nr: drop bleed-through constants
  (NULL_MSG_SENDER_CONTRACT_ADDRESS, DOM_SEP__HANDSHAKE_SECRET_HASH,
  DOM_SEP__MERKLE_HASH, DOM_SEP__NON_INTERACTIVE_HANDSHAKE_LOG_TAG,
  DOM_SEP__NULLIFIER_MERKLE, DOM_SEP__PARTIAL_NOTE_COMMITMENT,
  DOM_SEP__PUBLIC_DATA_MERKLE) introduced by other PRs.
- bot/factory.ts: adopt new DeployInstantiationOptions API; drop
  setupTokenWithOptionalEarlyRefuel / setupTokenContractWithOptionalEarlyRefuel
  / getTokenInstance helpers from an unbackported refuel PR; hoist instance
  variable so the post-if address read works on v4-next.
- e2e tests + cli-wallet/deploy.ts: adopt new DeployInstantiationOptions API
  (salt/deployer/universalDeploy/publicKeys move to construction); keep v4-next-only
  'wait: { returnReceipt: true }' callers compatible.
- aztec.js/api/contract.ts: keep DeployTxReceipt / DeployWaitOptions /
  DeployInteractionWaitOptions exports (v4-next-only).
- e2e_ha_full.test.ts: drop the keystore-reload test (introduced by an
  unbackported keystore-reload PR).
- token_bridge/index.ts: keep node.getProvenBlockNumber() (the new
  getBlockNumber('proven') ships with the unbackported getBlock RPC PR).

v4-next-staging keeps DeployTxReceipt / DeployWaitOptions and the
'wait: { returnReceipt: true }' API. The upstream PR removed
DeployInteractionWaitOptions and tightened the generic constraint to
extends InteractionWaitOptions. Switch DeployOptions, DeployReturn,
convertDeployOptionsToSendOptions, send overloads, and the deployAccounts
parameter type back to DeployInteractionWaitOptions so the v4-next-only
returnReceipt callers keep type-checking.

…v4-next (#23081)

Backport of #23041 to `backport-to-v4-next-staging`.

## Context

The automatic backport ([run
25543923430](https://github.com/AztecProtocol/aztec-packages/actions/runs/25543923430))
reported a cherry-pick failure, but a fresh cherry-pick of `719960de7d`
onto `backport-to-v4-next-staging` (HEAD `03f867bb5d`) applied cleanly
with **no conflicts**. The auto-backport likely raced against an
intermediate state. The resulting commit is byte-identical to the
original.

## Changes

Single commit cherry-picked from #23041:

- `yarn-project/aztec.js/src/aztec.js/src/wallet/wallet.ts` — adds
`sendMessagesAs: optional(schemas.AztecAddress)` to `SendOptionsSchema`
and `SimulateOptionsSchema` (the latter inherited by
`ProfileOptionsSchema`).
- `yarn-project/aztec.js/src/wallet/wallet.test.ts` — extends
`MockWallet` to capture last opts and adds assertions that
`sendMessagesAs` round-trips through the schema for `simulateTx`,
`profileTx`, and `sendTx`.

The underlying TS types (`SimulateInteractionOptions`,
`ProfileInteractionOptions`, `SendInteractionOptions`) already have
`sendMessagesAs?: AztecAddress` in `interaction_options.ts:121` on this
branch, so no extra changes were needed — only the schemas needed to
learn the field.

## Test plan

- Schema round-trip is exercised by `wallet.test.ts` (`WalletSchema`
describe block).

ClaudeBox log: https://claudebox.work/s/65355673e2d1830e?run=1

## Summary

Backport of
[#22985](#22985)
(`fix: better DeployMethod`) to `backport-to-v4-next-staging`.

The original PR refactors `DeployMethod` so that all address-affecting
parameters (`salt`, `deployer`, `universalDeploy`, `publicKeys`) are
locked in at construction time via a new `DeployInstantiationOptions`
argument, and removes the silent salt-cache poisoning bug where the
address could change between calls. See the migration notes added under
`## TBD` for the full API change.

## Commits

This backport preserves the standard 3-commit history so reviewers can
see exactly what conflicted and how it was resolved:

1. **`chore: cherry-pick #22985 ... with conflicts`** — raw `git
cherry-pick` result with conflict markers in place. Does not compile.
2. **`fix: resolve cherry-pick conflicts`** — resolution. Notable
choices:
- `migration_notes.md`: only the new DeployMethod note was added. Other
entries that came in via the cherry-pick (`getBlock` / `getCheckpoint`,
`feeAssetPriceModifier`, Domain separators, aztec-up table reformatting)
belong to PRs that have not been backported, so they were dropped to
avoid bringing in unrelated changes.
- `txe_oracles.nr`, `constants.nr`, `constants_tests.nr`: dropped
formatting-only diffs that depended on constants/types not present on
v4-next (`MAX_PRIVATE_LOGS_PER_TX`, `PRIVATE_LOG_SIZE_IN_FIELDS`,
`DOM_SEP__HANDSHAKE_SECRET_HASH`, `DOM_SEP__MERKLE_HASH`, etc.).
- `bot/src/factory.ts`: dropped the new
`setupTokenWithOptionalEarlyRefuel` /
`setupTokenContractWithOptionalEarlyRefuel` / `getTokenInstance` helpers
(introduced by an unrelated PR) and applied the new
`DeployInstantiationOptions` API to the existing `setupToken` flow.
- `e2e/composed/ha/e2e_ha_full.test.ts`: dropped the `should reload
keystore via admin API and keep building blocks after swapping
attesters` test that does not exist on v4-next.
- `docs/examples/ts/aave_bridge`, `docs/examples/ts/example_swap`: kept
deleted (modify/delete conflict — these examples don't exist on
v4-next).
- `docs/examples/ts/token_bridge/index.ts`: kept
`node.getProvenBlockNumber()` — the new `getBlockNumber('proven')` is
from a different PR.
- End-to-end tests, `aztec.js/src/api/contract.ts`, `bot`, etc.: adopted
the new `DeployInstantiationOptions` API; kept v4-next-only
`DeployTxReceipt` / `DeployWaitOptions` exports.
3. **`fix: restore DeployInteractionWaitOptions for v4-next
returnReceipt API`** — v4-next still supports `wait: { returnReceipt:
true }` (a feature added on v4-next that does not exist upstream). The
upstream PR removed `DeployInteractionWaitOptions` and tightened
`DeployOptions<W extends InteractionWaitOptions>`, which broke
type-checking for the existing `returnReceipt` callers. This commit
restores `DeployInteractionWaitOptions = NoWait | DeployWaitOptions |
undefined` and rewires `DeployOptions` / `DeployReturn` / `send` to use
it, so the v4-next-only `returnReceipt: true` callers keep
type-checking.

## Test plan
- [ ] CI green on this branch
- [ ] e2e_deploy_contract tests pass

ClaudeBox log: https://claudebox.work/s/2e03d384f1f73fd0?run=1

…ive handshake function (#22854)

cherry-pick of e67f943 with unresolved conflicts (markers preserved in history)

Drop incoming entries that don't exist on v4-next (DOM_SEP__MERKLE_HASH,
DOM_SEP__NULLIFIER_MERKLE, DOM_SEP__PARTIAL_NOTE_COMMITMENT,
DOM_SEP__PUBLIC_DATA_MERKLE) while keeping the two new ones added by
#22854 (DOM_SEP__HANDSHAKE_SECRET_HASH,
DOM_SEP__NON_INTERACTIVE_HANDSHAKE_LOG_TAG). HashedValueTester sized
<58, 51> = v4-next baseline <56, 49> + 2 new dom seps.

…902-aztec-up-shadow-fix

…es on PATH (#22902) (#23060)

Backport of #22902 to `backport-to-v4-next-staging`.

## Original change
Native binaries (`forge`, `nargo`, `anvil`, `bb`, …) now live in
`~/.aztec/current/internal-bin` (off `PATH`) and are exposed only via
`aztec-<tool>` symlinks in `~/.aztec/current/bin`. The `aztec`
entrypoint prepends `internal-bin` to its child `PATH` so workflows that
cross-call by basename keep working without leaking those names to the
user's shell.

## Cherry-pick conflict

One conflict during cherry-pick:

- `docs/docs-developers/docs/tutorials/js_tutorials/aave_bridge.md` —
*deleted by us, modified by them.* The file no longer exists on
`backport-to-v4-next-staging`, so the upstream modification has nothing
to apply against.

**Resolution:** dropped the file (matches v4-next state). The first
commit preserves the original cherry-pick result (file restored as
upstream had it) so reviewers can see what would have landed; the second
commit removes it.

No build fixes were needed — the change touches only shell installer
scripts, a standalone TS acceptance test, and docs. Shell syntax checked
with `bash -n` for all modified scripts.

## Commits
1. `fix(aztec-up): ...` — original cherry-pick result, including the
unresolvable file.
2. `fix: resolve cherry-pick conflicts` — drop `aave_bridge.md` to match
the target branch.

ClaudeBox log: https://claudebox.work/s/a57acc5286aef8a6?run=1

Splits `DeployMethod` into an abstract umbrella type plus three concrete
flavors that encode the deployer-lock state at the type level instead of
branching on a nullable field.

- `DeployMethod<T>` — abstract base, the type consumers use generically
(`let d: DeployMethod<MyContract> = ...`).
- `BoundDeployMethod` — locked to a concrete `deployer`.
- `UniversalDeployMethod` — locked to `AztecAddress.ZERO` (any sender).
- `PendingDeployMethod` — promotes into a `Bound`/`Universal` sibling on
the first `send` / `simulate` / `profile` call.

The three flavor-specific decisions (`getDeployerAddress`,
`lockOrAssertDeployer`, `cloneInstantiation`) are now abstract methods
rather than `if (this.deployer === undefined / equals(ZERO) / else)`
branches in the base.

Each subclass takes a narrowed instantiation type:

- `BoundInstantiationOptions` — `deployer` required, `universalDeploy:
never`.
- `UniversalInstantiationOptions` — `universalDeploy: true` required,
`deployer: never`.
- `PendingInstantiationOptions` — both `never`.

`new BoundDeployMethod(..., { universalDeploy: true })` is now a
TypeScript error. The runtime mutual-exclusion checks in subclass
constructors are gone; the only runtime guard left is
`BoundDeployMethod` rejecting `AztecAddress.ZERO` (a value-level
invariant the type system can't model).

Subclass constructors take named bundles instead of 9 positionals:

```ts
new BoundDeployMethod(wallet, contract, instantiation, payload?)
//                            ^               ^             ^
//   { artifact, postDeployCtor, args, constructorNameOrArtifact }
//                            { salt, publicKeys, deployer }
//                            { authWitnesses, capsules, extraHashedArgs }
```

`DeployMethod.create` follows the same shape. `Contract.deploy(wallet,
artifact, args, constructorName, instantiation)` and
`MyContract.deploy(wallet, ...args, instantiation?)` (codegen) are
**unchanged** — the bundle reshape stops at the `create` boundary.

- `DeployAccountMethod` now extends `UniversalDeployMethod` (account
contracts are always universal).

The conflict resolution in the previous commit accidentally dropped the
`extraHashedArgs = []` default in the destructuring of `with()`'s
options argument, which would otherwise cause `concat(undefined)` to
push an undefined entry.

…ock (#23100)

Cherry-picks f3911a8 feat(ci): Snapshots for aztec-nr contract
compilation failures and nargo expand (#23061).

Conflicts (rename/delete style — no text markers):
- noir-projects/contract-snapshots/test_programs/compile_failure/invalid_event/src/invalid_event.nr
  (renamed by #23061, deleted in v4-next-staging) — kept the renamed copy.
- noir-projects/noir-contracts-comp-failures/bootstrap.sh and
  noir-projects/noir-contracts-comp-failures/contracts/authorization_selector_collision/expected_error
  (deleted by #23061, modified in v4-next-staging) — left as-is in this
  commit (HEAD content), removed in the follow-up resolution commit so
  reviewers can see what conflicted.

Removes the two stray files (bootstrap.sh and authorization_selector_collision/expected_error)
that #23061 deleted as part of dropping the noir-contracts-comp-failures
crate. Both had been modified on v4-next-staging, which created the
rename/delete conflicts; the entire old crate is gone in #23061's
direction.

Re-runs the cargo-insta snapshot tests against the v4-next compiler and
the v4-next aztec-nr / contract code, accepting the diffs:

- compile_failure/authorization_selector_collision: one extra
  'check_parent_traits_are_implemented: missing trait ID' diagnostic on
  v4-next's authorization.nr.
- expand/avm_gadgets_test_contract: keccak_hash_300 doesn't exist on
  v4-next's avm_gadgets_test_contract.
- expand/avm_test_contract: ordering / minor signature differences on
  v4-next's avm_test_contract.

…23103)

Backport of #23033 (`feat: deploy method refactor 2`) onto
`backport-to-v4-next-staging`.

The automatic cherry-pick conflicted on
`yarn-project/aztec.js/src/contract/deploy_method.ts` (3 hunks) and
`yarn-project/aztec.js/src/wallet/deploy_account_method.ts` (1 hunk).

## Conflicts

A prior backport had introduced `DeployInteractionWaitOptions` and
renamed the runtime helper to `lockDeployerFromSendOptions` on this
branch — but #23033 was authored against `next` (which still used
`InteractionWaitOptions` and the old `lockDeployer`), so every line
mentioning either name conflicted. The new bundled-options shape of
`DeployMethod.with()` also conflicted with the old `new
DeployMethod(...)` call.

## Resolution

- Kept `DeployInteractionWaitOptions` (already in use everywhere on this
branch).
- Accepted #23033's `lockDeployer` — it's now the abstract method on
`DeployMethod` with per-subclass implementations, replacing the old
`lockDeployerFromSendOptions` helper.
- Accepted #23033's new `with()` signature and body verbatim (returns
`DeployMethod<TContract>`, routes through `DeployMethod.create(...)`
with bundled options).
- Dropped the `DeployMethod` import in `deploy_account_method.ts` — it
now extends `UniversalDeployMethod`. Kept `DeployInteractionWaitOptions`
(still used by `DeployAccountOptions` and the
`convertDeployOptionsToSendOptions` override).
- Restored the `extraHashedArgs = []` default in the `with()`
destructuring (lost during the merge — would have caused
`concat(undefined)` to push an undefined entry).

## Commits (per repo backport convention)

1. `feat: deploy method refactor 2 (#23033)` — original cherry-pick
recorded with conflict markers.
2. `fix: resolve cherry-pick conflicts` — only the conflict-marker hunks
edited.
3. `fix: restore extraHashedArgs default in DeployMethod.with()` —
behavior-parity fix.

## Build verification

Local `yarn build` was blocked by container-permission issues
(cargo-binstall / corepack both need writable home directories not
available here, and the noir submodule's JS packages couldn't be built
locally). Relying on CI to verify the build.

Detailed analysis:
https://gist.github.com/AztecBot/90777c90cf1d6d75c9755f9aeabf514d


ClaudeBox log: https://claudebox.work/s/115d4037a28ea1ad?run=2

…failures and nargo expand (#23061) (#23104)

Backport of #23061 to v4-next.

## Conflicts

The automatic cherry-pick failed with 3 rename/delete conflicts (no text
markers):

-
`noir-projects/contract-snapshots/test_programs/compile_failure/invalid_event/src/invalid_event.nr`
— renamed by #23061, deleted on v4-next-staging. Kept the renamed copy.
- `noir-projects/noir-contracts-comp-failures/bootstrap.sh` — deleted by
#23061, modified on v4-next-staging. Took #23061's deletion (the entire
`noir-contracts-comp-failures/` crate is gone).
-
`noir-projects/noir-contracts-comp-failures/contracts/authorization_selector_collision/expected_error`
— same as above.

## Commits

1. `feat(ci): cherry-pick #23061 (with conflicts)` — raw cherry-pick
result with the two stray files (`bootstrap.sh`, `expected_error`)
preserved as-is so reviewers can see what conflicted.
2. `fix: resolve cherry-pick conflicts` — removes those two stray files
in line with #23061's intent (the whole old crate is dropped).

## Verification

`cargo build --tests`, `cargo fmt --check`, and `cargo clippy
--all-targets` all pass for the new `noir-projects/contract-snapshots/`
crate. The compile_failure snapshots and `nargo expand` outputs are
exercised against the live Noir compiler in CI; any drift will surface
there.

ClaudeBox log: https://claudebox.work/s/9ae41fb6fbae7191?run=2